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REMARKS 

The Examiner is thanked for the performance of a thorough search and for the telephone 
interview conducted on March 4, 2008. By this amendment. Claim 1 has been amended. No 
claims have been added or canceled. Hence, Claims 1-28 are pending in the application. 

The amendments to the claims do not add any new matter to this application. 
Furthermore, the amendments to the claims were made to improve the readability and clarity of 
the claims and not necessarily for any reason related to patentability. All issues raised in the 
Office Action are addressed hereinafter. 

I. INTERVIEW SUMMARY 

Applicants thank the Examiner for the telephone interview conducted on March 4, 2008. 
Examiner McLean represented the USPTO and Applicants were represented by Karl T. Rees 
and Marcel Bingham. The parties discussed the differences between Claim 1 and the cited 
reference, Schwier. In particular. Applicants pointed out that Schwier does not teach a "merge 
utility" within the meaning of Claim 1 because Schwier never merges documents in a merge 
format using a merge utility on a computer system. The Examiner agreed that Schwier does not 
disclose a merge utility within the meaning of Claim 1. However, the Examiner expressed his 
belief that there may be other bases of rejection for Claim 1. Examiner did not specifically state 
what these bases for rejection might be, and Applicants dispute the existence of such bases for 
rejection. However, the Examiner did suggest several possibilities for amendments that may 
produce an allowable claim after another search. In the interest of expediting prosecution. 
Applicants agreed to file an RCE to enter several clarifying amendments based on the 
discussion. No agreement on allowable claim language was reached. 

n. CLAIM REJECTIONS BASED ON 35 U.S.C. § 102 

Claims 1-28 are rejected under 35 U.S.C. § 102(e) as allegedly anticipated by U.S. 
Patent No. 7,202,972 to Schwier, et al. (hereinafter Schwier). Applicants traverse the rejection. 
Reconsideration is respectfully requested. 
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INDEPENDENT CLAIM 1 

Claim 1, as set forth in the listing of claims, clarifies that the method features: 

receiving, at a merge utility executing on a computer system, a first 

merge document that is in a merge format; 
converting a second document from an original format to the merge 

format to create a second merge document; 

wherein the second document was created by a first document 
authoring application; 

wherein the step of converting is performed by either the merge 
utility or the first document authoring application; 

wherein the second merge document is in the merge format; 
using the merge utility executing on the computer system, merging 

the first merge document and the second merge document to 

generate a composite merge document; and 
after generating the composite merge document, delivering said 

composite merge document to an output device; 

wherein the output device is a device that is different from the 
computer system; 

wherein the original format is a format that is not supported by the output 
device, and therefore needs to be converted to another format that 
is supported by the output device in order to be properly 
interpreted by the output device; and 

wherein the merge format is a format that is supported by the output 
device, and therefore does not need to be converted to another 
format that is supported by the output device in order to be 
properly interpreted by the output device. 

For example, a computer system implementing the method of Claim 1 might feature a 
merge utility. The computer system may also feature a document authoring application. A user 
might create a document in the document authoring application (i.e. the second document). A 
user may wish to print this document with a pre-defined watermark. To do so, a user might 
click on a button that sends the document to the merge utility, along with another document (i.e. 
the first document, which may be, for example, a watermark). The merge utility would convert 
the document to a "merge format" capable of being understood by a printer (i.e. PCL). The 
other document (i.e. the watermark) may already be in this merge format. The two documents 
are merged together into one (i.e. the composite document). The merge utility may then deliver 
the composite document directly to the printer for printing. 

In Schwier, on the other hand, a user creates a single document comprising static data 
and variable data. Prior to being converted to a format suitable for printing, a filter event 
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separates the static data from the filter data. Schwier, col. 7, lines 7-17. Separately, the 
variable data and the static data are converted to a format suitable for printing. Schwier, col. 6, 
lines 49-56. The converted variable data and converted static data must be sent to a printer 
separately. E.g., Schwier, col. 6, lines 49-56. The printer stores the static data on the printer 
for re-use. Schwier, col. 6, lines 33-35. The printer then performs the step of merging the 
static data and the variable data back into a single document. Schwier, col 6, lines 63-65. The 
printer must be specially programmed to perform this step. 

Thus, Schwier fails to teach or suggest a number of features of Claim 1. 

(1) Schwier does not disclose "on the computer system, mersins faJ first merge 
document and fa] second merge document" that are in a "merge format. " 

For example, Schwier does not disclose "using the merge utility executing on the 
computer system, merging the first merge document and the second merge document" within 
the meaning of Claim 1. Claim 1 specifically requires that "the output device is a device that is 
different from the computer system." Claim 1 also specifically requires that the first merge 
document and the second merge documents are "in a merge format," which is defined to be "a 
format that is supported by the output device." Thus, for this element of Claim 1 to be 
satisfied, two documents in a format supported by an output device must be merged on a 
computer system that is different from the output device. 

Schwier does not teach or suggest such a merger. In Schwier, inputs are merged on two 
occasions. First, as relied upon by the Office Action in alleging that Schwier disclosed the 
quoted step, Schwier teaches that two inputs are merged at the application level. As depicted in 
Schwier FIG. 2, variable data (Var. 11) is merged with static data (Stat. 12) inside of an 
application (App. 12) to produce an EMF document (V-i-S (EMF) 13). This merger, however, 
does not teach the merging of Claim 1 because neither document is in a "merge format." 

At this point, it may be helpful to clarify several aspects of printing technology. 
Printing devices only understand (i.e. "support") documents in certain "raw" formats, such as 
PCL or PostScript. See, e.g., Schwier col. 10, lines 19-24 (Note that Office formats and EMF 
are not listed as printing languages). These formats are optimized for printing and are not 
conducive to editing. Thus, documents are typically edited in "original formats" that are more 
conducive to editing. Operating systems feature components such as printer drivers and 
spoolers that then convert these documents from their original format to a supported printing 
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format prior to sending the document to the printer. For example, spooler 50 in Schwier 
converts an EMF document to a printing language. Schwier at col. 9, lines 14—24. 

Because one skilled in the art would understand these fundamental aspects of printing 
technology, one skilled in the art would therefore understand that inputs 1 1 and 12 are not in a 
format "that is supported by the output device." Rather, inputs 1 1 and 12 appear to be in a 
Word or Excel format or, alternatively, in EMF. See, e.g., Schwier at col. 5, lines 30-38 and 
col. 6, lines 10-14. Neither of these formats is a "merge format" because, to Applicants' 
knowledge, no printer or other output device natively supports a Word, Excel, or EMF 
document. Because neither Var 1 1 or Stat 12 is in a merge format, Schwier' s merger V+S 
(EMF) 13 cannot be said to teach or suggest "merging the first merge document and the second 
merge document" within the meaning of Claim 1 . 

Though not reUed upon by the Office Action, ^c/iw/er teaches to merge inputs a second 
time when, in FIG. 2, printer 7 merges the PCL streams Var. 15 and Stat. 16 to form V+S 19. 
Applicants wish to clarify that this second merger also does not teach or suggest the merger of 
Claim 1. Claim 1 specifically requires the merger to take place "using the merge utility on the 
computer system." As Claim 1 presently clarifies, the "output device is different from the 
computer system." Since printer 7 clearly corresponds to an output device, Schwier' s merger 
V+S 19 takes place on an output device, and not on a computer system that is different from the 
output device, as required by Claim 1. 

(2) Schwier does not teach "after seneratins the composite merge document,, 
deliverine said composite merge document to an output device. " 

Also, Schwier does not teach or suggest "after generating the composite merge 
document, delivering said composite merge document to an output device." The Office 
Action alleges that "delivering said composite merge document to an output device" is taught in 
Schwier, FIG. 8. Applicants dispute this allegation. FIG. 8 does not teach a "composite merge 
document" in any sense. 

As FIG. 2 clearly shows, the only merged document to which Schwier' s output device 
(printer 7) has access is V+S 19. Applicants have already shown that V+S 19 cannot be a 
composite merge document because it is not generated as a result of merging, on a computer 
system, two documents that are in a merge format. Furthermore, even if V+S 19 were a 
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composite merge document, V+S 19 is never "delivered" to printer 7 — ^rather, printer 7 must 
generate V+S 19 itself. 

Finally, even if V+S 19 could be said to be a composite document "delivered" to 
printer 7, such delivery could not be said to occur "after generating the composite merge 
document." As FIG. 2 makes clear, V+S 19 is generated at printer 7. Therefore, V+S 19 
cannot be said to be delivered to printer 7 after V+S 19 has been generated. 

For at least the foregoing reasons, Schwier fails to teach or suggest at least one element 
of independent Claim 1. Therefore, Schwier does not anticipate Claim 1 under 35 U.S.C. § 
102. Reconsideration is respectfully requested. 

DEPENDENT CLAIMS 2-28 

Claims 2-28 depend from Claim 1, and include each of the above-quoted features by 
dependency. Thus, Schwier also fails to teach or suggest at least one feature found in Claims 
2-28. Therefore, Schwier does not anticipate Claims 2-28. Reconsideration of the rejection is 
respectfully requested. 

In addition, each of Claims 2-28 recites at least one feature that independendy renders it 
patentable. For example. Claim 13 features, among other elements: 

receiving, at the merge utility, a request to merge documents; 

wherein the steps of converting the second document and 

merging the first merge document and the second merge 
document are both performed in response to the merge 
utility receiving the request to merge documents. 

The Office Action alleges that "receiving, at the merge utility, a request to merge documents" is 
taught in Schwier by "the program code or device which enables the devices shown in Figure 1 
to initiate a request to merge conmiand." However, it is not apparent how any element of FIG. 
1 is "a request to merge documents." Furthermore, the Office Action fails to allege how and 
when such a request is received "at the merge utility." Nor does Schwier teach or suggest that 
"the steps of converting the second document and merging the first merge document and the 
second merge document are both performed in response to the merge utility receiving the 
request to merge document." 

As another example. Claim 9 features, among other elements: 
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passing [a] set of conversion instructions from the merge utility to the first 

document authoring application; and 
the first document authoring application generating the second merge document 

based on said set of conversion instructions. 

The Office Action alleges that "passing [a] set of conversion instructions to a document 
authoring application" may be found in Schwier, col. 4, lines 15-20. However, this portion of 
Schwier does not show a merge utility passing a set of instructions, as Claim 9 presently 
recites. Even more specifically, Claim 9 requires that merge utility pass the instructions to the 
document authoring application that created the second document. Schwier does not disclose 
or suggest anything like this. 

As another example. Claim 1 1 recites that "the composite merge document is in the 
merge format." Thus, as defined by Claim 1 1, a composite merge document must be in the 
merge format, and must be delivered to the output device. The Office Action alleges that such 
a composite merge document is disclosed in Schwier, lines 56-67. However, these lines merely 
describe how a single document containing variable and static data is converted to EMF format 
(a non-merge format) that is subsequently separated into two documents prior to being 
converted to PCL (a merge format). 

In fact, Schwier does not disclose a composite merge document within the meaning of 
Claim 1 1 . The static data and the variable data are separated before they are converted into a 
PCL (or other printer-compatible) data stream. Prior to this time, the combination of static and 
variable data cannot be considered a composite merge document, because it is not in the merge 
format. Since merger of the separated static and variable data does not occur until after the data 
has been sent to the printer, no "composite merge document" is ever "delivered" to Schwier'?. 
output device. Thus the merged document on the printer is also not a "composite merge 
document." 

As another example, Claim 12 recites that the "composite merge document is a template 
for creating other documents." The Office Action alleges that Schwier discloses this feature by 
virtue of the fact that Figure 5 of Schwier shows a master document. However, the master 
document of Figure 5 in Schwier is not a composite merge document. While Figure 5 does 
show a master document, this master document is not merged from two documents in the merge 
format, as is a composite merge document. Rather, the master document of Figure 5 is created 
at a document authoring program, and will subsequently be separated into static data and 
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variable data. At no time does Schwier disclose a composite merge document behaving as a 
template. 

To expedite prosecution in light of the fundamental differences already identified, 
further arguments for each independently patentable feature of Claims 2-28 are not provided at 
this time. Applicants reserve the right to further point out the differences between the cited art 
and the novel features recited in the dependent claims. 

m. CONCLUSION 

For the reasons set forth above, all of the pending claims are now in condition for 
allowance. The Examiner is respectfully requested to contact the undersigned by telephone 
relating to any issue that would advance examination of the present application. 

A petition for extension of time, to the extent necessary to make this reply timely filed, 
is hereby made. If applicable, a check for the petition for extension of time fee and other 
applicable fees is enclosed herewith. If any applicable fee is missing or insufficient, throughout 
the pendency of this application, the Commissioner is hereby authorized to any applicable fees 
and to credit any overpayments to our Deposit Account No. 50-1302. 

Respectfully submitted, 

HICKMAN PALERMO TRUONG & BECKER LLP 

Date: March 13, 2008 /KarlTRees#58983/ 

Karl T. Rees, Reg. No. 58,983 

2055 Gateway Place, Suite 550 
San Jose, CA 95110 
(408)414-1233 
Facsimile: (408) 414-1076 
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